fix security scan false positives for web-security skills#18
Merged
GangGreenTemperTatum merged 1 commit intoMay 22, 2026
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This change fixes a defensible false-positive path in the capabilities security scan workflow.
The failing GitHub Actions run was the
Security Scanworkflow onmainafter a runtime-only change to theweb-securitycapability. That change addedwaymore, but the workflow rescanned the entire capability root and failed on existing high and critical findings in offensive-security instructional content. Two classes of false positives were involved.First, the workflow scanned the whole capability directory with
--recursive --lenient. In lenient mode, the scanner falls back to treating plain markdown folders as pseudo-skills whenSKILL.mdis absent. That causedexploit-verifier/references/checklistsandexploit-verifier/references/ai-payloadsto be scanned as if they were skills, and their prompt-injection examples tripped the high-severity gate.Second, a small number of findings were policy mismatches for this repository’s intended content.
csp-bypasswas flagged byBEHAVIOR_BASH_TAINT_FLOWbecause the scanner interpreted the literal stringunsafe-evalinside agrepcommand as though the shell snippet were executingeval.blind-ssrf-chainswas flagged byYARA_command_injection_genericbecause it intentionally documents a literal exploit payload string inside an offensive-security skill.The fix is narrow. The workflow now scans
capabilities/<cap>/skillsinstead of the capability root, which limits scanning to actual skills and avoids pullingagentsandreferencesdirectories into fallback skill discovery. It also removes--lenientfrom the CI invocation so reference markdown is not treated as malformed skills. In the repository scan policy,BEHAVIOR_BASH_TAINT_FLOWandYARA_command_injection_genericare demoted toMEDIUMwith repository-specific rationale tied to instructional shell snippets and exploit payload examples in security skills.Validation was done locally by reproducing the failing scanner invocation, then rerunning it with the updated workflow target and policy. The
web-securityskill scan now passes thehighfailure threshold with zero critical and zero high findings. I also ranpre-commit run --files .github/workflows/security-scan.yml scan-policy.yaml, which passed, andjust validate, which passed with the repo’s existing local-tool warnings for optional environment checks.